Implementation of a reliable mobile payment depends on a secure and encrypted environment provided by a secure element (SE). Therefore, after an SE is properly used in a terminal, a mobile payment application can be installed on the SE to make a secure mobile payment. In addition to physical chip-based SEs, currently, a host card emulator (HCE) that is implemented by a terminal by using software is also regarded by a near field communication controller (NFCC) as an SE for management.
In some application scenarios, a terminal may expect that one SE, for example, an SE on a universal integrated circuit card (UICC), among multiple SEs is an exclusive SE and that the other SEs are non-exclusive SEs. In this case, when this UICC is connected to the terminal, a near field communication (NFC) communication peer selects, according to an NFC routing mechanism, only an application of the SE on this UICC, and therefore an application of another SE or an application of an HCE cannot be selected by the NFC communication peer. Therefore, it is possible that the terminal is required to allow activation of only the exclusive SE and is also required to deactivate a non-exclusive SE. In the prior art, a central processing unit (CPU) sends an SE setting instruction to the NFCC to control activation/deactivation of an SE, where the SE setting instruction includes an identifier (ID) of the SE that needs to be controlled.
If an exclusive UICC card is installed in the terminal, the HCE may be regarded as a non-exclusive SE, and the terminal should stop routing information received by using an NFC technology to the HCE. Generally, the terminal may implement control on an SE by using a mode setting instruction. Because a target ID of the mode setting instruction cannot be an ID of an HCE, an HCE cannot be deactivated by relying on the mode setting instruction, and an exclusive requirement of a newly connected exclusive SE cannot be ensured.